home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
kermit.columbia.edu
/
kermit.columbia.edu.tar
/
kermit.columbia.edu
/
newsgroups
/
misc.19941031-19941221
/
000224_news@columbia.edu_Mon Nov 21 04:54:30 1994.msg
< prev
next >
Wrap
Internet Message Format
|
1995-07-31
|
3KB
Received: from apakabar.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA02974
(5.65c+CU/IDA-1.4.4/HLK for <kermit.misc@watsun.cc.columbia.edu>); Mon, 21 Nov 1994 18:44:36 -0500
Received: by apakabar.cc.columbia.edu id AA28253
(5.65c+CU/IDA-1.4.4/HLK for kermit.misc@watsun); Mon, 21 Nov 1994 18:44:34 -0500
Path: news.columbia.edu!news.media.mit.edu!bloom-beacon.mit.edu!spool.mu.edu!agate!overload.lbl.gov!dog.ee.lbl.gov!news.cs.utah.edu!cc.usu.edu!jrd
From: jrd@cc.usu.edu (Joe Doupnik)
Newsgroups: comp.protocols.kermit.misc,alt.winsock
Subject: Re: winsock/pkt dvr hack possible?
Message-Id: <1994Nov21.105430.33454@cc.usu.edu>
Date: 21 Nov 94 10:54:30 MDT
References: <3a67j8$j39@Mercury.mcs.com> <3anvci$dut@relay.tor.hookup.net> <soren.223.000F87E0@aztec.co.za>
Organization: Utah State University
Lines: 29
Xref: news.columbia.edu comp.protocols.kermit.misc:1168 alt.winsock:22603
Apparently-To: kermit.misc@watsun.cc.columbia.edu
In article <soren.223.000F87E0@aztec.co.za>, soren@aztec.co.za (Soren Aalto) writes:
> In article <3aoc2h$bit@apakabar.cc.columbia.edu> jaltman@watsun.cc.columbia.edu (Jeffrey Altman) writes:
>
>>>> Jeff is correct. The top of a sockets API is a TCP stream channel of
>>>>bytes, not packets. "It could be done..." means creating a second TCP/IP
>>>>stack feeding from the streams channel and packaging it into TCP/IP over
>>>>Ethernet frames to be passed to the application. Not very desirable, nor
>>>>realistic.
>>>> Joe D.
<huge amount of repeated material omitted>
> And _that_ is the real problem. I have wondered at times if the
> TCP/IP stack functionality and the Comms/SLIP/PPP functionality
> shouldn't be separated into two programs--you could have a
> packet driver that "reflects" stuff & attach the comms driver
> for SLIP/PPP/whatever to one side and Winsock to the other.
-----------
Nice idea but not practical here. There are a great many
coupling threads (variables, calls) between the high level and comms
level material in Kermit so that control may be exercised and speed
retained. And there is much more to comms than serial or the internal
TCP/IP stack; SET PORT exhibits the list (and some choices transparently
encompass two or three variations from the same vendor).
Winsock is for pure Windows programs, not for DOS programs.
MS-DOS Kermit removes itself from comms channels when done with
them. Few commercial TCP/IP stacks do so (none that I know of). Were
winsock guys to get off the pot when done the problem would be smaller.
So please consider hounding your winsock vendor to go un-TSR upon last
close and to not be present until an application makes a demand.
Joe D.